Linear Regression Modeling For Load Factors

ABSTRACT

A system for linear regression modeling for load factors is disclosed. The system determines capacity, optimal authorizations, probabilities and models using a real-time iterative process throughout a period of time.

RELATED APPLICATIONS

This application is a continuation of, claims priority to and thebenefit of, U.S. Ser. No. 14/038,278 filed Sep. 26, 2013. The '278application is a continuation of and claims priority to, and the benefitof, U.S. Ser. No. 13/352,667 filed on Jan. 18, 2012 aka U.S. Pat. No.8,600,787 which issued on Dec. 3, 2013. The '667 application is acontinuation of and claims priority to, and the benefit of, U.S. Ser.No. 13/348,417 filed on Jan. 11, 2012. The '417 application claimspriority to and the benefit of U.S. Provisional Application No.61/561,245 filed on Nov. 17, 2011. Each of the aforementionedapplications are hereby incorporated by reference in their entirety.

FIELD OF DISCLOSURE

The present disclosure generally relates to a revenue maximizationsystem, and more particularly, to enabling forecasting and analysismethods and tools used as input to inventory control and revenuemanagement systems.

BACKGROUND

The transportation services industry, and particularly the airlineindustry, is often associated with high costs and varying degrees ofprofitability. As a result, airlines often seek new sources of income(e.g., ala carte pricing for additional services) and innovative ways toincrease revenues (e.g., optimizing existing processes). One such methodof increasing revenues involves offering for sale a greater number ofseats for any particular flight than is actually available on theflight. Such a strategy of authorizing more seats to be sold than thereexists in inventory is often referred to as an “overbooking” strategy.

Most airlines overbook because some passengers holding a confirmedreservation will not show up for the flight (“no-show”), and theresulting empty seats represent forgone revenue opportunity for theairline. Traditional overbooking strategies have proven to be effectivein generating increasing revenue, reducing costs and generally improvingoverall operational efficiencies for airlines. However, traditionaloverbooking optimization methods and systems often employ broadestimating techniques that produce only marginally accurate passengerno-show forecast and cost data. Thus, a long-felt need exists to providea robust, model driven, sophisticated and customizable revenuemaximization, cost forecasting and overbooking management system toenable accurate, timely and revenue maximizing data to the airlineoperation.

An overbooking strategy for a flight is accomplished by forecastingno-show rates, and then selling (i.e., overbooking) at a level thatminimizes costs associated with operating a flight with empty seats,while also minimizing the expected total costs of overbooking. In otherwords, overbooking costs include not only the revenue opportunity costof a flight with empty seats (spoiled seat (“SS”) costs), but also costsassociated with denying a passenger boarding on a flight due tooverbooking denied boarding (“DB”) costs. DB costs are incurred whenmore passengers show up than there are seats to accommodate them, andthe airline has to compensate such denied passengers with, for example,vouchers (e.g., for a discount off of future travel) and/or cashpayments (which may be established by law or regulation). Another costassociated with denying a passenger boarding is “ill-will,” which can bethought of as the opposite of good will, wherein accrues to the airlineand/or the airline's brand due to denied boardings.

SUMMARY

The present disclosure provides a forecasting and/or overbookingmanagement system that maximizes revenue (“MARS”), as disclosed invarious embodiments. MARS takes both the forecast of expected no-showsand the expected costs into account in formulating an overbookingstrategy.

In various embodiments, MARS may be configured to minimize costsassociated with the number of seats authorized to be sold for an airlineflight. MARS determines an SS cost for each seat in a plurality of seatsassociated with a flight, where the SS cost may be, for example, basedupon a current selling class of the flight and historic average faresassociated with the flight. MARS determines a denied boarding cost forthe flight. In various embodiments, the denied boarding cost is basedupon any subset or all of a wide variety of factors, including: anon-compensation factor, a voucher amount, a voucher breakage factor, anexpected percentage of volunteers, an factor, compensation associatedwith involuntary denied boarding (e.g., cash payment or a “draft”), anexpected accommodations cost for the denied passenger (e.g., hotel,meal, local transport, etc.), and/or a double denied boarding factor(e.g., the ripple effect on inventory due to reaccommodating the deniedpassenger on a future flight).

In minimizing the costs associated with overbooking airline seats, MARSdetermines a booked passenger no-show forecast (“NSF”) for each bookedpassenger associated with the flight. In various embodiments, the NSF isbased upon the complete passenger itinerary of each respectivepassenger, data indicating whether the respective passenger flew on aprevious leg of the passenger itinerary, and an adjustment factor basedupon historical NSF data. MARS determines a flight NSF by aggregatingthe booked passenger NSF and an unbooked passenger NSF.

In various embodiments, MARS determines an authorized seat allocationfor a flight by minimizing an overbooking cost based upon a cumulativespoiled seat cost, a cumulative denied boarding cost and the flight NSF.In various embodiments, MARS updates data (e.g., an authorizationparameter) associated with the flight based upon the authorized seatallocation. A reservation system and/or a revenue management system usesthe authorization parameter to determine a number of additional seats tobe sold for the flight and/or a price for each respective additionalseat.

In various embodiments, MARS calculates a flight authorization level(“AU”) that minimizes an overbooking cost associated with the flight,the flight with a coach seating capacity (“CAP”), wherein theoverbooking cost is based upon a spoiled seat SS cost and a deniedboarding (DB) cost, and wherein minimizing overbooking cost with respectto AU may be determined by:

$\sum\limits_{n = 0}^{\mu = {3\sigma}}{{P\left( {x = n} \right)} \times \left\lbrack {{SSCost}_{n} + {DBCost}_{n}} \right\rbrack}$where:  x = #  no  shows  for  a  fightSSCost_(n) = SSCost(max [n − (AU − CAP), 0])DBCost_(n) = DBCost(max [(AU − CAP) − n, 0])x ∼ Binominal(AU, p=^(″)No-Show-Rate^(″))${P\left( {x = n} \right)} \equiv {\begin{pmatrix}{AU} \\n\end{pmatrix}{p^{n}\left( {1 - p} \right)}^{({{AU} - n})}}$ μ = AU × p$\sigma = \sqrt{{AU} \times p \times \left( {1 - p} \right)}$

wherein DBcost_(n) is associated with the DB cost of the n^(th)passenger that is denied boarding and is determined by DBcost_(n)=DDB_(n)*[(1−ncf)*(voucher_amt*b*pv_(n)+(ill_will+exp_invol_cost_(n))*(1−pv_(n))+HMT_(n))],where

ncf=no compensation factor=the percentage of passengers denied boardingthat do not qualify to be compensated,

voucher_amt=an amount of a voucher offered to passengers who volunteerto DB,

b: Breakage factor, the expected percentage of voucher dollars that willbe used,

pv_(n): given n passengers who are denied boarding to the flight, pv_(n)is the expected percentage of volunteers;

ill_will: Extra cost added due to bad customer image and possible lossof customers due to involuntarily denying boarding to passengers;

exp_invol_cost_(n): an expected payout to an involuntary DB passenger;

HMT_(n)=an expected accommodation cost of the n^(th) DB passenger;

DDB_(n)=a double DB factor.

In various embodiments, the system may be configured to optimize AUbased upon at least one of:

HMT_(n) is not offered to voluntary DB passengers such that HMT_(n) isreduced by multiplying by the expected percentage of involuntarypassengers (1−pv_(n));

DDB_(n) is based on the probability that DB_(n) causes a ripple effectDB, wherein the ripple effect DB is associated with a DB on a differentflight; and

DDB_(n) is based on an expected cost of reaccommodating the rippleeffect DB.

In various embodiments, MARS calculates AUs for each scheduled flight inthe airline network. The calculating of the AUs for each flight in theairline network may be executed, for example, on a daily basis. Theperiodic calculation of AU may be based upon updated data associatedwith at least one of the voucher_amt, HMT_(n), DDB_(n) and market loadfactors. The periodic calculation of AU may be based upon updated inputdata to the SScost_(n) such as an update of a current selling class foreach flight and updated market load factors.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present disclosure may be derivedby referring to the detailed description and claims when considered inconnection with the Figures, wherein like reference numbers refer tosimilar elements throughout the Figures, and:

FIG. 1 is a block diagram illustrating major system components forforecasting and overbooking management, in accordance with variousembodiments;

FIG. 2 is a process flow diagram showing a process for determining aflight authorization level that minimizes overbooking costs, inaccordance with various embodiments;

FIG. 3 is a process flow diagram showing a process for determiningflight NSF, in accordance with various embodiments;

FIG. 4 is a graph showing an overbooking cost model in accordance withvarious embodiments;

FIG. 5 is a process flow diagram showing a process for dynamicallycalculating costs, in accordance with various embodiments; and

FIG. 6 is a process flow diagram showing a process for determining anupgrade solution, in accordance with various embodiments.

DETAILED DESCRIPTION

The present invention fundamentally changes the way organizationscalculate and/or implement revenue maximization and/or cost minimizationstrategies. For example, MARS enables airlines to:

-   -   formulate more precise predictions regarding whether a        particular passenger will show up for a particular leg (e.g.,        flight) of a passenger itinerary; such forecasts may be based        upon a comprehensive analysis of itinerary data and taking into        account data associated with previously flown legs, a next        active leg and subsequently scheduled legs;    -   forecast costs associated with denying passengers boarding on a        particular flight, for every flight each day, factoring in the        actual passengers booked, market load factors, double denied        boarding costs, hotel costs, and probability a denied boarding        will result in a voucher or a cash payment;    -   dynamically calculate costs by analyzing re-accommodation        dependencies;    -   forecast costs associated with an empty seat on a particular        flight, individually for every flight each day, factoring in the        current selling class and historic average fares;    -   implement a strategy that authorizes more seats to be sold in        coach based upon seats in first class by calculating expected        marginal seat revenue (“EMSR”) for each first class seat and        comparing it to an EMSR for each potential additional sale of a        coach seat; in various embodiments, EMSR may be adjusted for the        risk of double selling a unit of inventory (e.g., a seat);    -   implement just in time inventory and releasing additional seats        for sale in the coach cabin based upon EMSR and coach cabin        demand;    -   adjust, in near real time, for booking in first/envoy class        cabin by, for example, decreasing the risk of double selling a        seat (e.g., selling the same physical seat to two customers);        and    -   optimize voucher pricing (e.g., the value, often in the form of        a credit, offered to passengers who voluntarily get “bumped”        from a flight when the flight is overbooked).

While the disclosure may discuss airlines and “flights” for purposes ofconvenience and illustration, one of skill in the art will appreciatethat the overbooking and revenue maximization method and tools discussedherein apply to any transportation industry; e.g., buses, cruise ships,passenger trains, etc.

Various embodiments of the present invention employ forecasting,statistical analysis and/or optimization techniques. For moreinformation regarding such techniques refer to, for example: “The Theoryand Practice of Revenue Management” (International Series in OperationsResearch & Management Science) by Kalyan T. Talluri and Garrett J. vanRyzin; “Using Multivariate Statistics (5th Edition)” by Barbara G.Tabachnick and Linda S. Fidell; and “Introduction to OperationsResearch” by Friedrich S. Hiller and Gerald J. Lieberman, McGraw-Hill7th edition, Mar. 22, 2002; the contents of which are each herebyincorporated by reference in their entireties.

While the embodiments described herein are described in sufficientdetail to enable those skilled in the art to practice the invention, itshould be understood that other embodiments may be realized and thatlogical and mechanical changes may be made without departing from thespirit and scope of the invention. Thus, the detailed description hereinis presented for purposes of illustration only and not of limitation.

For the sake of brevity, conventional data networking, applicationdevelopment and other functional aspects of the systems (and componentsof the individual operating components of the systems) may not bedescribed in detail herein. Furthermore, the connecting lines shown inthe various figures contained herein are intended to representfunctional relationships and/or physical couplings between the variouselements. It should be noted that many alternative or additionalfunctional relationships or physical connections may be present in apractical system.

In various embodiments, MARS includes a user interface (“UI”), softwaremodules, logic engines, numerous databases, interfaces to systems andtools, and/or computer networks. While MARS may contemplate upgrades orreconfigurations of existing processing systems, changes to existingdatabases and system tools are not necessarily required by the presentinvention.

The benefits provided by this disclosure include, for example, increasedrevenue, increased forecasting accuracy, lower costs, increased seatutilization, increased customer good will, increased planning andoperational efficiency and increased employee morale. For example, arevenue management organization benefits from increased accuracy insetting inventory levels and predicting costs. Customers benefit from amore detailed and sophisticated double booking management strategy thatminimizes the number of involuntary boarding denials.

While the description references specific technologies, systemarchitectures and data management techniques, practitioners willappreciate that this description is but various embodiments and thatother devices and/or methods may be implemented without departing fromthe scope of the invention. Similarly, while the description referencesa user interfacing with the system via a computer user interface,practitioners will appreciate that other interfaces may include mobiledevices, kiosks and handheld devices such as mobile phones, smartphones, tablet computing devices, etc.

“Entity” may include any individual, software program, business,organization, government entity, web site, system, hardware, and/or anyother entity.

A “user” may include any entity that interacts with a system and/orparticipates in a process. With reference to FIG. 1, user 105 mayperform tasks such as requesting, retrieving, receiving, updating,analyzing and/or modifying data, initiating, manipulating, interactingwith or using a software application, tool, module or hardware, andinitiating, receiving or sending a communication. User 105 may interfacewith Internet server 125 via any communication protocol, device ormethod discussed herein, known in the art, or later developed. User 105may be, for example, a member of a revenue management organization, amember of an operations research and systems analysis organization, adownstream system, a third-party system, a system administrator, etc.

In various embodiments, with reference to FIG. 1, system 101 may includea user 105 interfacing with a MARS 115 by way of a client 110. MARS 115may be a partially or fully integrated system comprised of varioussubsystems, modules and databases. Client 110 comprises any hardwareand/or software suitably configured to facilitate entering, accessing,requesting, retrieving, updating, analyzing and/or modifying data. Thedata may include operational data (e.g., schedules, resources, routes,operational alerts, weather, etc.), passenger data, cost data,forecasts, historical data, verification data, asset (e.g., airplane)data, inventory (e.g., airplane seat) data, legal/regulatory data,authentication data, demographic data, transaction data, or anyinformation discussed herein.

Client 110 includes any device (e.g., a computer), which communicates,in any manner discussed herein, with the MARS 115 via any networkdiscussed herein. Browser applications comprise Internet browsingsoftware installed within a computing unit or system to conduct onlinecommunications and transactions. These computing units or systems maytake the form of personal computers, mobile phones, personal digitalassistants, mobile email devices, laptops, notebooks, hand-heldcomputers, portable computers, kiosks, and/or the like. Practitionerswill appreciate that client 110 may or may not be in direct contact withthe MARS 115. For example, client 110 may access the services of MARS115 through another server, which may have a direct or indirectconnection to Internet server 125. Practitioners will further recognizethat client 110 may present interfaces associated with a softwareapplication (e.g., SAS analytic software) or module that are provided toclient 110 via application GUIs or other interfaces and are notnecessarily associated with or dependant upon internet browsers orinternet specific protocols.

User 105 may communicate with the MARS 115 through a firewall 120 tohelp ensure the integrity of the MARS 115 components. Internet server125 may include any hardware and/or software suitably configured tofacilitate communications between the client 110 and one or more MARS115 components.

Firewall 120, as used herein, may comprise any hardware and/or softwaresuitably configured to protect MARS 115 components from users of othernetworks. Firewall 120 may reside in varying configurations includingstateful inspection, proxy based and packet filtering, among others.Firewall 120 may be integrated as software within Internet server 125,any other system 101 component, or may reside within another computingdevice or may take the form of a standalone hardware component.

Authentication server 130 may include any hardware and/or softwaresuitably configured to receive authentication credentials, encrypt anddecrypt credentials, authenticate credentials, and/or grant accessrights according to pre-defined privileges associated with thecredentials. Authentication server 130 may grant varying degrees ofapplication and data level access to users based on information storedwithin authentication database 135 and user database 140. Applicationserver 145 may include any hardware and/or software suitably configuredto serve applications and data to a connected client 110.

According to various embodiments, MARS 115 is used to maximize revenueand/or manage inventory strategy, such as an airline seat overbookingstrategy. With reference again to FIG. 1, MARS 115 allows communicationwith CDR 150 and with various other databases, tools, UIs and systems(not shown in FIG. 1). Such systems include, for example, airlinescheduling systems, passenger booking and reservations systems, revenuemanagement systems and inventory systems.

MARS 115 components are interconnected and communicate with one anotherto allow for a completely integrated revenue maximization andoverbooking management, forecasting and inventory management system. Invarious embodiments, MARS 115 communicates with external systems anddatabases 160 to, for example, share results and other data. Forexample, in embodiments of the system, MARS 115 formulates passengershow rate (or no-show rate) and cost prediction models, and airlinereservations systems (external Systems and databases 160) sell inventorybased upon the MARS 115 output.

MARS 115 modules (e.g., upgrade analyzer 146, Optimizer 147, Cost Engine148, no-show forecaster (“NSF”) 149 and other MARS 115 modules not shownin FIG. 1) are software modules configured to enable online functionssuch as sending and receiving messages, receiving query requests,configuring responses, dynamically configuring user interfaces,requesting data, receiving data, displaying data, executing complexprocesses, calculations, forecasts, mathematical techniques, workflowsand/or algorithms, prompting user 105, verifying user responses,authenticating the user, initiating MARS 115 processes, initiating othersoftware modules, triggering downstream systems and processes,encrypting and decrypting. Additionally, MARS 115 modules may includeany hardware and/or software suitably configured to receive requestsfrom client 110 via Internet server 125 and application server 145.

MARS 115 modules may be further configured to process requests, executetransactions, construct database queries, and/or execute queries againstdatabases, within system 101 (e.g., central data repository (“CDR”)150), external data sources and temporary databases. In variousembodiments, one or more MARS 115 modules may be configured to executeapplication programming interfaces in order to communicate with avariety of messaging platforms such as, for instance, email systems,wireless communications systems, mobile communications systems,multimedia messaging service (“MMS”) systems, short messaging service(“SMS”) systems, and the like.

MARS 115 modules may be configured to exchange data with other systemsand application modules, such as, for example an airline reservationsystem. In various embodiments, MARS 115 modules may be configured tointeract with other system 101 components to perform complexcalculations, retrieve additional data, format data into reports, createXML representations of data, construct markup language documents,construct, define or control UIs, and/or the like. Moreover, MARS 115modules may reside as stand-alone systems or tools or may beincorporated with the application server 145 or any other MARS 115component as program code. As one of ordinary skill in the art willappreciate, MARS 115 modules may be logically or physically divided intovarious subcomponents such as a workflow engine configured to evaluatepredefined rules and to automate processes.

In addition to the components described above, MARS 115 may furtherinclude one or more of the following: a host server or other computingsystems including a processor for processing digital data; a memorycoupled to the processor for storing digital data; an input digitizercoupled to the processor for inputting digital data; an applicationprogram stored in the memory and accessible by the processor fordirecting processing of digital data by the processor; a display devicecoupled to the processor and memory for displaying information derivedfrom digital data processed by the processor; and a plurality ofdatabases.

As will be appreciated by one of ordinary skill in the art, one or moresystem 101 components may be embodied as a customization of an existingsystem, an add-on product, upgraded software, a stand-alone system(e.g., kiosk), a distributed system, a method, a data processing system,a device for data processing, and/or a computer program product.Accordingly, individual system 101 components may take the form of anentirely software embodiment, an entirely hardware embodiment, or anembodiment combining aspects of both software and hardware. Furthermore,individual system 101 components may take the form of a computer programproduct on a computer-readable storage medium having computer-readableprogram code means embodied in the storage medium. Any suitablecomputer-readable storage medium may be utilized, including hard disks,CD-ROM, optical storage devices, magnetic storage devices, and/or thelike.

Client 110 may include an operating system (e.g., Windows XP, WindowsNT, 95/98/2000, Windows 7, Vista, OS2, UNIX, Linux, Solaris, MacOS,Windows Mobile OS, Windows CE, Palm OS, Symbian OS, Blackberry OS, J2ME,etc.) as well as various conventional support software and driverstypically associated with mobile devices and/or computers. Client 110may be in any environment with access to any network, including bothwireless and wired network connections. In various embodiments, accessis through a network or the Internet through a commercially availableweb-browser software package. Client 110 and MARS 115 components may beindependently, separately or collectively suitably coupled to thenetwork via data links which include, for example, a connection to anInternet Service Provider (“ISP”) over the local loop as is typicallyused in connection with standard wireless communications networks and/ormethods, modem communication, cable modem, Dish networks, ISDN, DigitalSubscriber Line (“DSL”). In various embodiments, any portion of client110 may be partially or fully connected to a network using a wired(“hard wire”) connection. As those skilled in the art will appreciate,client 110 and/or any of the system components may include wired and/orwireless portions.

Internet server 125 may be configured to transmit data to client 110within markup language documents. “Data” may include encompassinginformation such as commands, messages, transaction requests, queries,files, data for storage, and/or the like in digital or any other form.Internet server 125 may operate as a single entity in a singlegeographic location or as separate computing components located togetheror in separate geographic locations. Further, Internet server 125 mayprovide a suitable web site or other Internet-based graphical userinterface, which is accessible by users (such as user 105). In variousembodiments, the Microsoft Internet Information Server (“IIS”),Microsoft Transaction Server (“MTS”), and Microsoft SQL Server, are usedin conjunction with the Microsoft operating system, Microsoft NT webserver software, a Microsoft SQL Server database system, and a MicrosoftCommerce Server. In various embodiments, Linux, Apache, Informix MySQLand PHP hypertext processor are used to enable MARS 115. Additionally,components such as Access or Microsoft SQL Server, Oracle, Sybase,InterBase, etc., may be used to provide an Active Data Object (“ADO”)compliant database management system.

Like Internet server 125, application server 145 may communicate withany number of other servers, databases and/or components through anymeans known in the art. Further, application server 145 may serve as aconduit between client 110 and the various systems and components ofMARS 115. Internet server 125 may interface with application server 145through any means known in the art including a LAN/WAN, for example.Application server 145 may further invoke software modules such as theOptimizer 147, automatically or in response to user 105 requests.

Any of the communications, inputs, storage, databases or displaysdiscussed herein may be facilitated through a web site having web pages.The term “web page” as it is used herein is not meant to limit the typeof documents and applications that may be used to interact with theuser. For example, a typical web site may include, in addition tostandard HTML documents, various forms, Java applets, JavaScript, activeserver pages (“ASP”), common gateway interface scripts (“CGI”), Flashfiles or modules, FLEX, ActionScript, extensible markup language(“XML”), dynamic HTML, cascading style sheets (“CSS”), helperapplications, plug-ins, and/or the like. A server may include a webservice that receives a request from a web server, the request includinga URL (e.g., http://yahoo.com/) and an internet protocol (“IP”) address.The web server retrieves the appropriate web pages and sends the data orapplications for the web pages to the IP address. Web services areapplications that are capable of interacting with other applicationsover a communications means, such as the Internet. Web services aretypically based on standards or protocols such as XML, SOAP, WSDL andUDDI. Web services methods are well known in the art, and are covered inmany standard texts. See, e.g., Alex Nghiem, IT Web Services: A Roadmapfor the Enterprise (2003).

FIG. 1 depicts databases that are included in various embodiments of theinvention. An exemplary list of various databases used herein includes:an authentication database 135, a user database 140, CDR 150 and/orother databases that aid in the functioning of the system. Aspractitioners will appreciate, while depicted as separate and/orindependent entities for the purposes of illustration, databasesresiding within system 101 may represent multiple hardware, software,database, data structure and networking components. Furthermore,embodiments are not limited to the databases described herein, nor doembodiments necessarily utilize each of the disclosed databases.

Authentication database 135 may store information used in theauthentication process such as, for example, user identifiers,passwords, access privileges, user preferences, user statistics, and thelike. User database 140 maintains user information and credentials forMARS 115 users (e.g., user 105).

CDR 150 is a data repository that may be configured to store a widevariety of comprehensive data for MARS 115. While depicted as a singlelogical entity in FIG. 1, those of skill in the art will appreciate thatCDR 150 may, in various embodiments, consist of multiple physical and/orlogical data sources. In various embodiments, CDR 150 stores operationaldata, schedules, resource data, asset data, inventory data, personnelinformation, routes and route plans, station (e.g., airports or otherterminals) data, operational alert data, weather information, passengerdata, reservation data, cost data, optimization results, booking classdata, forecasts, historical data, verification data, authenticationdata, demographic data, legal data, regulatory data, transaction data,security profiles, access rules, content analysis rules, audit records,predefined rules, process definitions, financial data, and the like. Forexample, a data source or component database of CDR 150 includespassenger name record (“PNR”) data for an airline, historical voluntaryvoucher cost information, historical show rates for markets and/ormarket segments and for particular passenger attributes, route andschedule data, airline equipment characteristics, pricing data, etc.

Any databases discussed herein may include relational, hierarchical,graphical, or object-oriented structure and/or any other databaseconfigurations. Common database products that may be used to implementthe databases include DB2 by IBM (Armonk, N.Y.), various databaseproducts available from Oracle Corporation (Redwood Shores, Calif.),Microsoft Access or Microsoft SQL Server by Microsoft Corporation(Redmond, Wash.), MySQL by MySQL AB (Uppsala, Sweden), or any othersuitable database product. Moreover, the databases may be organized inany suitable manner, for example, as data tables or lookup tables. Eachrecord may be a single file, a series of files, a linked series of datafields or any other data structure. Association of certain data may beaccomplished through any desired data association technique such asthose known or practiced in the art. For example, the association may beaccomplished either manually or automatically. Automatic associationtechniques may include, for example, a database search, a databasemerge, GREP, AGREP, SQL, using a key field in the tables to speedsearches, sequential searches through all the tables and files, sortingrecords in the file according to a known order to simplify lookup,and/or the like. The association step may be accomplished by a databasemerge function, for example, using a “key field” in pre-selecteddatabases or data sectors. Various database tuning steps arecontemplated to optimize database performance. For example, frequentlyused files such as indexes may be placed on separate file systems toreduce In/Out (“I/O”) bottlenecks.

One skilled in the art will also appreciate that, for security reasons,any databases, systems, devices, servers or other components of system101 may consist of any combination thereof at a single location or atmultiple locations, wherein each database or system includes any ofvarious suitable security features, such as firewalls, access codes,encryption, decryption, compression, decompression, and/or the like.

The systems and methods may be described herein in terms of functionalblock components, screen shots, optional selections and variousprocessing steps. It should be appreciated that such functional blocksmay be realized by any number of hardware and/or software componentsconfigured to perform the specified functions. For example, the systemmay employ various integrated circuit components, e.g., memory elements,processing elements, logic elements, look-up tables, and the like, whichmay carry out a variety of functions under the control of one or moremicroprocessors or other control devices. Similarly, the softwareelements of the system may be implemented with any programming orscripting language such as C, C++, C#, Java, JavaScript, Flash,ActionScript, FLEX, VBScript, Macromedia Cold Fusion, COBOL, MicrosoftActive Server Pages, assembly, PERL, SAS, PHP, awk, Python, VisualBasic, SQL Stored Procedures, PL/SQL, any UNIX shell script, andextensible markup language (XML) with the various algorithms beingimplemented with any combination of data structures, objects, processes,routines or other programming elements. Further, it should be noted thatthe system may employ any number of conventional techniques for datatransmission, signaling, data processing, network control, and the like.Still further, the system could be used to detect or prevent securityissues with a client-side scripting language, such as JavaScript, VBScript or the like.

Software elements may be loaded onto a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions that execute on thecomputer or other programmable data processing means for implementingthe functions specified in the flowchart block or blocks. These computerprogram instructions may also be stored in a computer-readable memorythat can direct a computer or other programmable data processingapparatus to function in a particular manner, such that the instructionsstored in the computer-readable memory produce an article of manufactureincluding instruction means which implement the function specifiedherein or in flowchart block or blocks. The computer programinstructions may also be loaded onto a computer or other programmabledata processing apparatus to cause a series of operational steps to beperformed on the computer or other programmable apparatus to produce acomputer-implemented process such that the instructions which execute onthe computer or other programmable apparatus provide steps forimplementing the functions specified in the flowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions. Further, illustrations ofthe process flows and the descriptions thereof may make reference touser windows, web pages, web sites, web forms, prompts, etc.Practitioners will appreciate that the illustrated steps describedherein may comprise in any number of configurations including the use ofwindows, web pages, web forms, popup windows, prompts and/or the like.It should be further appreciated that the multiple steps as illustratedand described may be combined into single web pages and/or windows buthave been expanded for the sake of simplicity. In other cases, stepsillustrated and described as single process steps may be separated intomultiple web pages and/or windows but have been combined for simplicity.

Referring again to FIG. 1, in various embodiments, user 105 logs onto anapplication (e.g., a module) and Internet server 125 may invoke anapplication server 145. Application server 145 invokes logic in the MARS115 modules by passing parameters relating to user's 105 requests fordata. MARS 115 manages requests for data from MARS 115 modules and/orcommunicates with system 101 components. Transmissions between user 105and Internet server 125 may pass through a firewall 120 to help ensurethe integrity of MARS 115 components. Practitioners will appreciate thatthe invention may incorporate any number of security schemes or none atall. In various embodiments, Internet server 125 receives requests fromclient 110 and interacts with various other system 101 components toperform tasks related to requests from client 110.

Internet server 125 may invoke an authentication server 130 to verifythe identity of user 105 and assign roles, access rights and/orpermissions to user 105. In order to control access to the applicationserver 145 or any other component of MARS 115, Internet server 125 mayinvoke an authentication server 130 in response to user 105 submissionsof authentication credentials received at Internet server 125. When arequest to access system 101 is received from Internet server 125,Internet server 125 determines if authentication is required andtransmits a prompt to client 110. User 105 enters authentication data atclient 110, which transmits the authentication data to Internet server125. Internet server 125 passes the authentication data toauthentication server 145 which queries the user database 140 forcorresponding credentials. When user 105 is authenticated, user 105 mayaccess various applications and their corresponding data sources.

With reference again to FIG. 1, in various embodiments, an optimizermodule (e.g., Optimizer 147) receives input from a forecaster module(e.g., NSF 149) and one or more cost forecaster and analysis engines(e.g., Cost Engine 148). The optimizer module determines an optimalbooking allocation (aka “authorization level” or “AU”) for an airlineflight. In various embodiments, upgrade analyzer 146 receives a first AUcalculation and calculates an upgrade adjusted AU based upon an EMSRcalculation.

With reference now to FIG. 2, a process for determining the AU thatminimizes overbooking costs is shown. Cost Engine 148 forecasts aspoiled seat (“SS”) cost for each seat in a plurality of seatsassociated with a flight (Step 205). In various embodiments, the SS costis based upon at least one of a current selling class of the flight andhistoric fares associated with the flight.

Cost Engine 148 forecasts a denied boarding (“DB”) cost for the flight(Step 210). In various embodiments, forecasting the DB cost includesassessing the probability that each DB passenger will volunteer to nottake the flight or that the passenger with be denied boardinginvoluntarily.

NSF 149 determines a booked passenger no-show forecast (“NSF”) for eachpassenger associated with the flight (Step 215). In various embodiments,the booked passenger NSF is based upon a subset of the booked passengerassociated with the flight. In various embodiments, the booked passengerNSF is based upon the next active leg of a passenger's itinerary. Thenext active leg may not correspond to the flight that is being analyzed.

NSF 149 aggregates the booked passenger NSF and an unbooked passengerNSF to create a flight NSF (Step 220). Optimizer 147 determines anauthorized seat allocation for the flight that minimizes an overbookingcost, where the overbooking cost is based upon an accumulation of eachSS cost, the DB cost and the flight NSF (Step 225).

MARS 115 updates an authorization parameter for the flight based uponthe AU (Step 230). In various embodiments, the authorization parameteris obtained, received and/or accessed by a reservation system and/orrevenue management system that uses the AU to determine a number ofadditional seats to be sold for the flight and a respective price foreach additional seat.

No-Show Forecast (“NSF”)

In various embodiments, NSF 149 may be configured to forecast a no-showrate for every passenger booked in a flight using their passenger namerecord (“PNR”) characteristics. NSF 149 determines the likelihood that aparticular passenger will show up for a flight based upon traditionalfactors such as passenger demographics, historic no-show data fromsimilar flights, etc. Additionally, in various embodiments, NSF 149performs a comprehensive analysis of itinerary data for each particularpassenger in determining the show rate (aka the no-show-forecast or“NSF”).

NSF is based upon and, in various embodiments, proportional to a no-showrate; the terms NSF and no-show rate may be used interchangeably herein.“No-show rate” may be thought of as the complement of the probability ofshow, i.e., 1−NSF=probability of show. PNR characteristics include datastored, collected or accessible by airlines such as: outbound origintype indicator, local/flow indicator, frequent flyer status, offline OAindicator, e-ticket indicator, time of day, advanced purchase range,refundability indicator, service class, day of week, multiple passengerin itinerary, next active leg, outbound vs. return, number of legs beingtraveled, order of the flight under analysis with other legs in theitinerary, etc.

In various embodiments, CDR 150 includes historical PNR data andhistorical show rate data. Historical show rate data is analyzed bydirectional markets and/or regions and may also be analyzed by PNRcharacteristic. “Directional Market” includes a flight in one directionbetween one particular point and another. Thus, Boston to ReaganWashington (BOS→DCA) is considered a different directional market thanReagan Washington to Boston (DCA→BOS).

In various embodiments, NSF 149 comprises a historical data processingengine that applies various statistical methods to historical PNR datain order to generate forecast coefficients based on historical showrates for various market and passenger characteristics and combinationsof characteristics. Such statistical methods include, for example,regression techniques such as logistic regression. Thus, in variousembodiments, determining an NSF for a particular passenger comprisesdetermining the forecast market for the passenger and aggregating theappropriate forecast coefficients associated with historical passengerdata with similar PNR characteristics.

With reference now to FIG. 3, a process for determining flight NSF invarious embodiments is shown. NSF 149 determines a NSF for each bookedpassenger of the flight and aggregates the individual booked passengerNSF's into a flight level booked passenger NSF. In various embodiments,for the booked passenger NSF, NSF 149 accesses PNR data for the flightbeing analyzed from CDR 150 (Step 305). NSF 149 analyzes the PNR dataand, for each passenger booked on the flight, determines the next activeleg for the passenger. Based upon the next active leg, NSF 149 assigns aforecast market (Step 310). As discussed above, in various embodiments,NSF 149 may analyze PNR data for a subset of booked passengers.

Based upon the forecast market and PNR characteristics, NSF 149retrieves NSF coefficients for the passenger (Step 315). For instance,NSF 149 may determine that the forecast market is Washington, D.C. toPhoenix, Ariz. (DCA→PHX) and that the passenger is an outboundpassenger, without other passengers on his itinerary and the ticket waspurchased for the flight in the 14-21 day AP range. In variousembodiments, NSF 149 retrieves forecast coefficients from the forecastmarket data area (e.g. table/row/column) of CDR 150 and NSF 149aggregates the various forecast coefficients to determine a show rate(or NSF) to associate with the passenger.

In various embodiments, default rules may determine how to handle NSFdata that is incomplete, missing, outside of expected bounds, etc. Forinstance, NSF 149 may determine that forecast coefficient data for aparticular forecast market is based upon a sample size that is too smallto be statistically significant and, for example, apply a default rulethat directs NSF 149 to use unbooked NSF data in place of the bookedpassenger historical NSF data (Step 320). Other default rules may directNSF 149 to use a predetermined value assigned to the forecast market(Step 325). Default rules may be nested, cumulative, stored in code(hard coded), stored in a database and/or derived based upon conditionssuch as time of year, day of week, etc.

NSF 149 aggregates the individual booked passenger NSFs to determine abooked passenger NSF for the flight (Step 330). In various embodiments,NSF 149 may apply an adjustment to the booked passenger NSF (Step 335)to, for example, ensure that the booked passenger NSF for the flight iswithin certain upper and lower bounds. Such upper and lower bounds maybe stored, calculated or derived and may be based upon statisticalanalysis, the experience or intuition of experts, etc.

NSF 149 determines an unbooked passenger NSF for the flight. In variousembodiments, a historical show rate by directional market based onbooking period is used to predict a show rate to associate with unbookedseats of the flight. Unbooked seats are the seats yet to be reserved bya passenger. Unbooked NSF may be based upon historical averages and as afunction of time. The function of time may represent the booking periodas designated by the days before a flight is scheduled to depart.Booking period may be referred to as the advanced purchase (AP)timeframe. AP is a typical term in the airline industry and many airlinerate structures are based upon AP with rate restrictions associated witha particular AP.

Thus, for example, a reference table in CDR 150 may store a historicalshow rate for passengers who booked a flight at a given AP and/or insideof a given date before a flight. For example, for a directional marketx→y, the show rate might be 0.85 for the +60 AP, 0.90 for the +30 AP and0.97 for the seven day AP. The reference table may store information atthe directional market level. In various embodiments, some directionalmarkets may not have data comprehensive enough upon which to base showrate or NSF forecasts. NSF 149 may use market segment data in the casewhere specific directional market data is inadequate (e.g.,insufficient, missing, known to be inaccurate, etc.).

With reference again to FIG. 3, NSF 149 determines the days untildeparture of the flight that is being analyzed (Step 340) and determinesa directional market associated with a flight. NSF 149 accesses unbookedpassenger historical data based upon the days until departure and thedirectional market and determines an unbooked passenger NSF (Step 345).In various embodiments, default rules may determine how to handleunbooked passenger NSF data that may be, for example, missing,incomplete, outside of expected bounds or variances, etc. For instance,NSF 149 may determine that the unbooked NSF data for a particulardirectional market and timeframe is incomplete and, for example, apply adefault rule that directs NSF 149 to use unbooked NSF data for a marketgroup associated with the directional market (Step 350). For example, ifthe data for Cedar Rapids→Chicago is incomplete, the default rule maydirect NSF 149 to use Des Moines→Chicago data, or the default rule maydirect NSF 149 to use Iowa (aggregated)→Chicago data. Other defaultrules may direct NSF 149 to use a predetermined value for the market(Step 355). Default rules for determining unbooked passenger NSF may benested, may be stored in code (hard coded), in a database and/or derivedbased upon conditions such as time of year, day of week, etc.

In various embodiments, the number of unbooked seats associated with theflight at any given time is calculated based on an AU of the flight lessthe number of bookings (i.e., booked/sold tickets): # UnbookedSeats=(Capacity−# Booked Passengers*(Booked Show Rate))/(Unbooked ShowRate).

In various embodiments, the booked passenger NSF may be aggregated withan unbooked seat NSF to determine a flight NSF (Step 360). NSF 149 mayapply an adjustment to the flight NSF in order to, for example, ensurethat the flight NSF is within certain bounds (Step 365). For example, invarious embodiments, flight show rates are bounded by findingQ1−1.5*(Q3−Q1) of the historical show rates of flights at the marketlevel, where Q1=25th percentile and Q3=75th percentile.

Next Active Leg

As discussed above, in various embodiments, NSF 149 determines an NSF(or probability of show) based on historic show rates for the nextactive leg (“NAL”) in the passenger itinerary. In various embodiments,based upon the itinerary data, NSF 149 determines a historic show rateof passengers with similar characteristics and identical or similar(e.g., same start and end points plus similar departure time or day ofweek) NAL of a passenger's itinerary.

Traditional systems and methods for forecasting whether a bookedpassenger will show for a flight typically do not differentiate betweenpassengers based upon their itinerary. For example, consider a flightfrom Washington, D.C. (DCA) to Boston, Mass. (BOS) where passenger 1 andpassenger 2 are both booked passengers for the flight. NSF 149 maypredict an NSF for passenger 1 and passenger 2 based upon historicaldirectional market data and passenger profile data (class of servicebooked, how far in advance the ticket was purchased, etc.). In variousembodiments, NSF 149 determines a passenger NSF for a particular flightbased, at least partially, upon the NAL for the passenger.

For example, if passenger 1's itinerary comprises one leg (DCA→BOS) andpassenger 2's itinerary comprises two legs (PHX→DCA and DCA→BOS), NSF149 analyzes the NSF for these passengers differently. In variousembodiments, NSF 149 determines the NAL for each passenger. Sincepassenger 1 is only scheduled for one leg, passenger 1's NAL is the sameflight as the flight that is under analysis, namely, DCA→BOS. NSF 149determines the passenger forecast market to be the directional market ofDCA→BOS. NSF 149 determines the NSF of passenger 1 based upon forecastcoefficients associated with the DCA→BOS directional market.

In various embodiments, the forecast coefficients for a particulardirectional market may be determined in a variety of ways; for example,the forecast coefficient may be stored in a table and the table may beupdated periodically (e.g., daily, weekly or monthly) based upon actualshow/no-show data for particular passenger characteristics associatedwith the forecast market.

Continuing the above example, NSF 149 may determine Passenger 2's NSF asdifferent from Passenger 1's NSF even if, for example, all othercharacteristics regarding the passengers were identical. Passenger 2 isscheduled to fly two legs so, in various embodiments, passenger 2's NSFfor the flight being analyzed by NSF 149 depends upon passenger 2's NAL;i.e., whether passenger 2 has flown leg 1 (PHX→DCA), or not. In thisexample, if NSF 149 determines that passenger 2 has yet to fly leg 1,then NSF 149 determines the NAL for passenger 2 to be PHX→DCA, eventhough the flight being analyzed is DCA→BOS; in other words, sincepassenger 2 has yet to show for the first of a two-leg itinerary, NSF149 uses the forecast coefficients based upon the first leg (i.e., theNAL), in determining passenger 2's NSF for the passenger's second leg.Thus, since passenger 2's NAL is PHX→DCA, NSF 149 uses PHX→DCA data todetermine passenger 2's NSF for the DCA→BOS flight.

Continuing the same example, if NSF 149 determines that passenger 2 hasalready flown leg 1, then DCA→BOS is the NAL and NSF 149 assigns DCA→BOSas the forecast market for passenger 2 and determines forecastcoefficients based upon DCA→BOS in assigning the passenger 2's NSF forthe DCA→BOS flight. One of skill in the art will recognize that theabove example merely illustrates embodiments and is not presented forpurposes of limitation.

Outbound vs. Return

In various embodiments, when analyzing the booked passenger NSF for aparticular flight, NSF 149 considers where the flight is with respect tothe order of all the legs in the passenger itinerary. For example, NSF149 may consider whether a passenger has flown a portion of theitinerary, is en route, or is on a return segment when forecasting theNSF for the particular passenger for the particular leg.

For example, consider a forecast for a flight from DCA→BOS. Passenger1's itinerary comprises one leg: DCA→BOS. Passenger 2's itinerarycomprises four legs: Outbound: Leg1-BOS→DCA; Leg2-DCA→PHX; Return:Leg3-PHX→DCA; Leg4-DCA→BOS. Assume that passenger 2 has already flownlegs 1-3. In various embodiments, on the itineraries depicted in theexample above, for the purpose of determining NSF, MARS 115 considersotherwise similar passengers as fundamentally different. This exampleillustrates two of the various considerations NSF 149 uses inforecasting a passenger NSF for a flight: “outbound vs. return” and“connecting flight.” MARS 115, and specifically NSF 149, takes intoconsideration an outbound passenger's (e.g., itinerary 1 in the aboveexample) probability of show is likely to be different than a passengeron an intermittent leg or a return portion of their trip (e.g. passenger2 in the above example). Furthermore, in various embodiments, NSF 149forecasts the NSF for passenger 1 and passenger 2 differently becausepassenger 2 is a connecting passenger (from PHX) and passenger 1 is anoriginating passenger. For example, in various embodiments, NSF 149calculates the NSF for passenger 2's leg 4 as a joint probability (i.e.,NSF for leg 4 depends upon passenger 2's NSF for leg 3) and/or aconditional probability (e.g., whether or not passenger 2 has alreadyflown leg 3).

In addition to the methods discussed above, in various embodiments, NSF149 may be configured to calculate NSF for particular passengers basedupon one or more of the following methods or factors: NSF or marketcoefficient is at least partially determined using logistic regression;NSF for a passenger is determined based upon a previous leg flown and/orfuture scheduled legs; a feedback loop adjusts the forecasted bookedshow rate to account for errors in forecast (e.g. an experienced basedadjustment factor is applied to the forecast); etc.

Cost Forecaster

Cost Engine 148 may be configured to forecast costs associated withoverbooking. In various embodiments, MARS 115 enables forecasting DBcosts and SS costs. If the AU is set too high, more passengers mightshow for a flight than there are seats on the airplane for thepassengers. DB costs include all the costs associated with denying apassenger boarding on a flight. SS costs include all the costsassociated with flying an airplane with an empty seat (e.g., the lostrevenue associated with not selling enough tickets so that seatutilization is 100% on the flight).

Denied Boarding (DB) Costs

Several factors contribute to the cost associated with an airlinedenying a passenger boarding on a flight for which the passengerpossesses a ticket. In various embodiments, Cost Engine 148 forecasts DBcosts individually for every flight, each day, factoring in the actualpassengers booked, market load factors, hotel costs, and probability adenied boarding will result in a voucher or a draft. The DB cost iscalculated at the flight level and also takes into account the differentaccommodation options (e.g. hotel, meals and transportation) available.

FIG. 4 shows an example of calculating denied boarding cost given anexemplary voucher cost of $400 (405). The vertical axis (430) indicatesthe total expected cost and the horizontal axis (435) indicates thenumber of passengers denied boarding. In various embodiments, deniedboarding cost may be modeled as an aggregate, for each passenger deniedboarding, of a breakage adjusted voucher cost (410), an involuntary ratedraft cost (425), a rolling denied boarding marginal cost (i.e., doubledenied boarding costs) (415) and a secondary hotel, meal andtransportation cost (420). In various embodiments, Cost Engine 148 takesinto account an estimate that considers that not all vouchers issued byan airline will be redeemed by a passenger. Thus, gross voucher cost maybe adjusted by a “breakage factor.”

Cost Engine 148 may also consider the effect on future flights of adenied boarding of the current flight. Cost Engine 148 employssophisticated data analysis and forecasting algorithms that are able toassess the cumulative effect, across the airline's entire network, ofexcess passengers in the system; e.g., the effect associated withpassengers who may be denied boarding on a particular flight,rescheduled for a later flight and cause that later flight to denyboarding of a different passenger. As shown in FIG. 4, rolling DBmarginal cost (415) takes this phenomenon into account.

In various embodiments, Cost Engine 148 determines the cost of eachdenied boarding passenger for a flight based upon the following:

DBcost_(i)=DDB_(i)*[(1−ncf)*(voucher_amt*b*pv_(i)+(ill_will+exp_invol_cost_(i))*(1−pv_(i))+HMT_(i))];where,

-   -   DB cost_(i): DB cost of the i^(th) passenger who is denied        boarding;    -   ncf: No Compensation Factor, the percentage of DBs that do not        qualify to be compensated due to non-compliance, 0≦ncf≦1;    -   voucher_amt: The actual amount of the voucher offered to        passengers who volunteer to DB (i.e., voluntarily get “bumped”        from the flight);    -   b: Breakage factor, the expected percentage of voucher dollars        that will be used, 0≦b≦1 (breakage factor can also be thought of        as the voucher utilization factor);    -   pv_(i): Given i DBs, pv_(i) is the expected percentage of        volunteers, calculated from a linear regression model using        historical data, 0≦pv≦1;    -   ill_will: The extra cost added due to bad customer image and        possible loss of customers due to involuntarily denying boarding        to passengers;    -   exp_invol_cost_(i): The expected payout to an involuntary DB        passenger;    -   HMT_(i): The expected hotel, meal and transportations costs of        the i^(th) DB passenger, based on the time to accommodate the        passenger; and,    -   DDB_(i): Double DB factor, increases the DB cost based on the        probability that this DB causes another DB. DDB_(i) increases        depending on the load factor of an entire directional market and        the station load factor for that day. DDB_(i)≧1.

MARS 115 also includes a voucher analysis and pricing module to reducecosts by minimizing both involuntary draft costs (i.e., payments toinvoluntary passengers that are denied boarding) and voucher outlays(i.e., vouchers given to passengers who voluntarily opt to not travel ona flight).

In various embodiments, MARS 115 evaluates flights occurring in a giventimeframe (e.g., the next 24 hours) on an iterative basis (e.g., every30 minutes) on the criteria used in the DB calculations. A flight mayhave low expected DB costs in the morning, but due to operational issues(cancellation, downgrade, weather, a political event) have much higheractual DB costs. Costs are minimized by adjusting the voucher offer fora particular flight throughout the day based on the most currentconditions.

In various embodiments, MARS 115 calculates a plurality of AUs for,respectively, each scheduled flight in airline network. In response tocalculating the plurality of AUs, Cost Engine 148 calculates, on aperiodic basis the DBcost_(n) for each flight scheduled for departure inthe next x-number hours (e.g., x=24, a rolling 24 hour time period). Invarious embodiments, the periodic basis may be based upon a schedule(e.g., every 30 minutes) and/or may be based upon an operational factorsuch as, for example, to assess the impact of flight cancellations,weather, a political event (e.g., terrorism), an economic event, or aflight maintenance issue.

In various embodiments, MARS 115 determines a plurality of affectedflights among flights scheduled for departure in the next twenty-fourhours that are affected by an operational factor and adjusts an actualvoucher offer amount for a subset of flights in the plurality ofaffected flights.

Dynamic Calculation of Re-Accommodation Costs

In various embodiments, DB cost is dynamically calculated based upon aplurality of forecasts for a re-accommodation cost for each of aplurality of denied passengers for a flight. When passengers are DB fora flight, they are typically reaccommodated on a later flight.Predicting the costs associated with such re-accommodation can becomplex since each reaccommodated passenger takes up a seat on a futureflight which decreases the number of re-accommodation options availablefor the next DB passenger.

In various embodiments, Optimizer 147 and Cost Engine 148 work inconjunction with each other to dynamically determine there-accommodation costs for a given DB passenger based uponre-accommodation options and taking into account re-accommodationoptions that may have been eliminated by other DB passengers. Forexample, the cost for a 3^(rd) DB passenger may depend on number ofre-accommodation options and how the 1^(st) and 2^(nd) DB passenger werere-accommodated.

With reference now to FIG. 5, in various embodiments, when determiningthe DB Costs for a flight, Cost Engine 148 determines a re-accommodationcost for each possible number of DB passengers. Cost Engine 148determines the forecasted number of denied passengers for the flight.The number of forecasted denied passengers for the flight may be basedupon the CAP, the AU and/or the NSF for the flight.

Cost engine analyzes a plurality of flights in an airline network toidentify a plurality of alternate accommodation (AA) flights that coverat least the same directional market as the flight (Step 505). CostEngine 148 analyzes the booking information for each flight in theplurality of AA flights (Step 510). Cost Engine 148 selects a first AAflight for the first DB. For example, a flight is scheduled for Phoenixto Pittsburgh (PHX→PIT) on Day 1 at 12 pm. Cost Engine 148 identifiesthe following AA flights:

AA₁: PHX→PIT on Day 1 at 4 pm

AA₂: PHX→CLT→PIT on Day 1 at 5 pm

AA₃: PHX→PIT on Day 1 at 8 pm

AA₄: PHX→PIT on Day 2 at 7 am

AA₅: PHX→CLT→PIT on Day 2 at 8 am

In the above example, Cost Engine 148 may assign the first deniedpassenger to be reaccommodated on the first AA flight (DB₁:AA₁) and maydetermine that AA₁ can still accommodate more passengers and assign thesecond denied passenger to the same flight (DB₂:AA₁). However, basedupon the re-accommodations DB₁ and DB₂ on AA₁, there may not be enough“room” on any AA flight for DB₃ until AA₄ on the next day. Thus, indetermining the DB Costs for each DB, Cost Engine 148 may not include ahotel, meal and transportation (HMT) cost for DB₁ and DB₂ but mayinclude an HMT as part of DBCost₃.

In various embodiments, Cost Engine 148 may also adjust the double DBfactor component of a potential DB for a different flight. For example,if booking information suggests that re-accommodation of a 3^(rd) DBpassenger on AA₄ would influence the probability that passenger alreadybooked on the AA₄ flight would now be denied boarding on that flight,Cost Engine 148 assesses this cost to the system and incorporates theDDB cost in DBCost₃.

With reference again to FIG. 5, Cost Engine 148 selects for a firstdenied passenger a first AA flight from the plurality of AA flights,wherein the first denied passenger is one of the plurality of deniedpassengers (Step 515). Based upon the selecting the first AA flight forthe first denied passenger, Cost Engine 148 selects for a second deniedpassenger a second AA flight from the plurality of AA flights (Step520). In response to the second AA flight being scheduled to depart on adifferent day than the flight (Step 525), Cost Engine 148 adjusts the DBcost associated with the second denied passenger to account for hotel,meal and/or transport (HMT) costs (Step 530).

Spoiled Seat (SS) Costs—

SS Cost is the cost associated with a flight flying with an empty seat.Airlines typically consider empty seats on flights as revenue that maynever be recaptured. In various embodiments, Cost Engine 148 forecastsSS costs based upon various factors such as the closure level for theflight, day of week, historical market average fares and advancepurchase (“AP”) range. “Closure level” means the lowest fare class forthat flight. “AP Range” means the advanced purchase interval prior to aflight's actual day of departure. Since fares generally increase as aflight approaches the scheduled departure date, spoiled seat costs aregenerally more expensive a few days before the flight departs than acouple months before the flight departs. Thus, in various embodiments,Cost Engine 148 calculates SS costs based upon a time factor such as theAP range and/or the actual timeframe (e.g., number of days) before theflight is scheduled to depart.

Cost Engine 148, calculates a SS cost for each potential spoiled seat ona flight. The first SS for a flight (i.e., SS₁) can be thought of as thepredicted value of selling one more seat on the plane. In variousembodiments, Cost Engine 148 determines additional SS costs using anexponential decay function such as the exemplary function:SSi=d^(i-1)SS_(i−1), where 0<d<1 is calculated using historical fares bymarket and Advance Purchase.

Optimizer

In various embodiments, Optimizer 147 receives input from NSF 149 andCost Engine 148 to determine an overbooking strategy for a flight. Giventhe no-show rate, Optimizer 147 evaluates the risk of denied boardings(DB cost) against missed revenue potential (SS Cost). In variousembodiments, Optimizer 147 may employ a variety of statistical modelsand/or optimization methods in order to determine the optimaloverbooking strategy. In various embodiments, Optimizer 147 assumes thatthe actual show rate follows a binomial distribution with an exemplarymathematical formulation as shown below:

  Min{E[Overbooking  Cost]}   w.r.t  to  AU${E\left\lbrack {{Overbooking}\mspace{14mu} {Cost}} \right\rbrack} = {\sum\limits_{n = 0}^{\mu = {3\sigma}}{{P\left( {x = n} \right)} \times \left\{ {{{{\begin{matrix}{{SSCost}\mspace{14mu} \left( {\max \left\lbrack {{n - \left( {{AU} - {CAP}} \right)},0} \right\rbrack} \right)} \\\left. {{DBCost}\left( {{{\max\left\lbrack {\overset{+}{AU} - {CAP}} \right)} - n},0} \right\rbrack} \right)\end{matrix}\mspace{20mu} {subject}\mspace{14mu} {to}\text{:}\mspace{11mu} {CAP}} \leq {AU} \leq {1.12 \times {CAP}\mspace{20mu} {where}\text{:}\mspace{14mu} n} \sim {{Binomial}\mspace{11mu} \left( {{AU},{p = {{No}\mspace{14mu} {Show}\mspace{14mu} {Rate}}}} \right)\mspace{20mu} {P\left( {x = n} \right)}} \equiv {\begin{pmatrix}{AU} \\n\end{pmatrix}{p^{n}\left( {1 - p} \right)}^{{AU} - n}\mspace{20mu} \mu}} = {{AU} \times p}},{\sigma = \sqrt{{AU} \times p \times \left( {1 - p} \right)}}} \right.}}$

Thus, the optimal AU is determined as the AU that minimizes expectedoverbooking costs and the expected overbooking cost is calculated as asummation of overbooking costs across a show rate distribution; i.e.,P(x=n) is determined based upon a statistical distribution (binomial)that depends on a historical no-show rate.

In order to illustrate the embodiment shown in the above equation,consider a flight where CAP=100 and NSF=0.95 (no-show rate=5%,).Optimizer 147 calculates the expected overbooking costs for a range ofAUs=100, 101, . . . 112 and chooses the AU with the minimum expectedcost. To further illustrate the model, consider how Optimizer 147, inthe illustrated embodiment, calculates the expected overbooking costwhen AU=102:

-   -   n=the range of no-shows; the possibilities are zero no-shows        (n=0), one no-show (n=1), two no-shows (n=2) . . . n={AU*5%+3*σ.        For AU=102, the upper bound for n works out to 12 (rounded from        11.7). σ=the standard deviation of the distribution.    -   P(x=n) is the probability that the number of no-shows will equal        n no-shows and the model sums the probability weighted        overbooking cost (SS cost and DB cost) for each n;

The following illustrates the calculation of overbooking cost for n=3,given CAP=100, AU=102.

-   -   P(x=3) can be calculated from the binomial distribution;    -   Spoiled Seat        Cost=SSCost(max[3−(102−100),0]=SSCost(max[1,0])=SSCost(1).        Intuitively, if an airline sells 102 tickets, (AU=102), given        expect 3 no-shows (n=3), only 99 (102−3) passengers will show-up        for the flight. Hence we will spoil only 1 seat given our CAP of        100 and the spoiled seat at AU=102 is =SSCost(1).    -   DB Cost=DBCost(max[(102−100)−3,0])=DBCost(max[−1,0])=DBCost(0).        This implies when there are 3 no-shows for a cabin with 100        seats (CAP=100) and 102 seats are sold for the cabin (AU=102),        there will be no passengers denied boarding.

Upgrade Solution

MARS 115 may include upgrade analyzer 146 module. Upgrade solutionrefers to a method of further optimizing the overbooking solution byconsidering additional cabins' (e.g. first class cabin) seats in theoverbooking analysis. In various embodiments, MARS 115 determines anoptimal number of additional seats that can be sold as coach seats withthe intent of upgrading the passengers to the first and/or businessclass cabin.

One reason why upgrade solution analysis is an effective strategy for anairline is due to space available complimentary upgrades typicallygranted to certain passengers. Such passengers are comprised primarilyof frequent fliers who book in the coach cabin but often receive a freeupgrade to the first class or business cabins. Since these passengersare booked in coach (e.g., paid coach level prices for their ticket),airlines do not want to consider such complimentarily upgrade passengersin passenger demand for first class when deciding how many extra seatsto add in the coach cabin as an upgrade solution.

In various embodiments, upgrade analyzer determines achievable demand(Step 605), for instance by adding the bookings for coach to demand forcoach seats at any time (=t). Upgrade analyzer 146 determines that theremay be excess demand for coach seats and less demand for first/businessclass seats (Step 610). Upgrade analyzer 146 may be configured toexecute an EMSR process to determine if the seats should be sold ascoach and/or first/business class seats.

In various embodiments, upgrade analyzer 146 calculates the EMSR foreach first class (Step 615) seat and compares it to an EMSR for eachpotential additional sale of a coach seat (Steps 620 and 625). Invarious embodiments, this EMSR is adjusted for the risk of double sell.In this context, a double sell refers to a situation where a first/envoyclass seat is offered and sold at coach prices and that seat is alsosold as a first/envoy class seat. Thus, there are two booked passengersallocated to the same physical seat on the airplane. This situationoften leads to an involuntary denied boarding which is associated withhigh cost due to government mandated cash payments and due to thegenerated.

In various embodiments, determining an effective upgrade solution istime sensitive. EMSR is a function of demand and the likelihood that aticket will be sold: EMSR=demand_(t)×p(sell)_(t). The number of units(seats) demanded (aka “achievable demand”) generally decreases as timegets closer to the departure time of the flight (T=0). Thus, one outputof upgrade analyzer 146 includes the time aspect of when to sell andupgrade seats. In various embodiments, as long asEMSR_(coach)>=EMSR_(first), upgrade solution seats are released for salethe excess demand is managed off to a level such that, (Coach AchievableDemand−Error)<=(Coach Optimized AU+# Coach Upgrade Seats).

If the EMSR of excess coach demand exceeds the EMSR of first/envoyclass, additional seats are made available to the coach cabin (Step625). In various embodiments, MARS 115 mitigates the risk of a doublesell; within a predefined timeframe before a scheduled departure, MARS115 analyzes flight booking, forecasting and cost data every half hourto adjust the number of upgrade seats being authorized by MARS 115.

With reference now to FIG. 5, in various embodiments, Upgrade Analyzer146 obtains an achievable coach seat demand for a flight(demand_(coach)) of an airplane. There are a number of seats on theairplane and the seats are associated with at least one of a first classof service (first) and a second class of service (coach). Achievabledemand_(coach) may be calculated, in various embodiments, as bookingsfor coach seats plus the demand for coach seats for a timeframe from ananalysis date to a date of departure of the flight (Step 505). Invarious embodiments, achievable demand_(coach) is adjusted to accountfor an error in a forecast, wherein the achievable demand is based uponthe forecast.

Upgrade Analyzer 146 executes an upgrade analysis to determine that anupgrade seat should be sold, the upgrade process includes:

i) determining that there is excess demand in coach (demand_(coach)); invarious embodiments, determining that there is excess demand_(coach)includes determining that the achievable demand_(coach)>the total numberof seats in coach (CAP) (Step 510);

ii) determining an expected marginal seat revenue for a sale of anadditional first class seat (EMSR_(first)) on the flight EMSR_(first)(=a seat_(first) demand price X a probability that seat_(first) will besold) (Step 515);

iii) determining an expected marginal seat revenue for a sale of anadditional coach seat (EMSR_(coach)) on the flight as EMSR_(coach) (=aseat_(coach) demand price X a probability that seat_(coach) will besold) (Step 520); and,

iv) if EMSR_(coach)>EMSR_(first), updating an upgrade authorizationparameter indicating that an additional upgrade seat on the flightshould be offered for sale.

In various embodiments, Upgrade Analyzer obtains seat_(coach) demandprice and the seat_(first) demand price from an external system such asa pricing system or a revenue management system. The demand prices maybe determined based upon a timeframe from an analysis date to a date ofdeparture of the flight; e.g., the number of days until the flightdeparts.

In various embodiments, Upgrade Analyzer 146 repeats the upgradeanalysis for all unbooked first class seats. In various embodiments,Upgrade Analyzer 146 repeats the upgrade analysis until at least one of:EMSR_(coach)<=EMSR_(first); the total upgrade seats>=a predeterminedmaximum; the total upgrade seats>=a predetermined percentage of thetotal number of seats in coach (CAP); and the total upgrade seats>=apredetermined percentage of the total number of seats in first class.

Traditionally, overbooking systems make first class cabin seatsavailable for sale as an “upgrade seat” immediately, based on theforecast of front cabin and coach demand meeting the conditionsdescribed above, i.e., seats are released for sale after the excessdemand is managed off to a level such that, (Coach AchievableDemand−Error)<=(Coach Optimized AU+# Coach Upgrade Seats). In variousembodiments, MARS 115 may be configured to recognize that demandforecasts generally improve closer to departure (a seat demand forecast200 days prior to departure is much less reliable than one 14 daysprior). In various embodiments, MARS 115 releases additional seats forsale in the coach cabin when the conditions above for managing excessdemand are met AND coach cabin demand approaches the optimal total coachseats to sell (with a margin of error for over forecasts).

In various embodiments, Upgrade Analyzer 146 determines an optimal timeto authorize the total number of upgrade seats to be sold and, at theoptimal time, update the upgrade authorization parameter to equal thetotal upgrade seats. Determining the optimal time may includedetermining that achievable demand_(coach)<=an authorized number ofseats to be sold in coach (AU)+total upgrade seats.

By implementing just in time inventory, MARS 115 increases yields on theadded seats and reduces the risk of incorrect allocation of upgradeseats on a flight without enough demand to justify the added seats,which can have the effect of lowering yields.

While the steps outlined above represent specific embodiments of theinvention, practitioners will appreciate that there are any number ofcomputing algorithms and user interfaces that may be applied to createsimilar results. The steps are presented for the sake of explanationonly and are not intended to limit the scope of the invention in anyway. Benefits, other advantages, and solutions to problems have beendescribed herein with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any element(s) that maycause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as critical, required, or essentialfeatures or elements of any or all of the claims of the invention.

Systems, methods and computer program products are provided. In thedetailed description herein, references to “various embodiments”, “oneembodiment”, “an embodiment”, “an example embodiment”, etc., indicatethat the embodiment described may include a particular feature,structure, or characteristic, but every embodiment may not necessarilyinclude the particular feature, structure, or characteristic. Moreover,such phrases are not necessarily referring to the same embodiment.Further, when a particular feature, structure, or characteristic isdescribed in connection with an embodiment, it is submitted that it iswithin the knowledge of one skilled in the art to effect such feature,structure, or characteristic in connection with other embodimentswhether or not explicitly described. After reading the description, itwill be apparent to one skilled in the relevant art(s) how to implementthe disclosure in alternative embodiments.

It should be understood that the detailed description and specificexamples, indicating embodiments of the invention, are given forpurposes of illustration only and not as limitations. Many changes andmodifications within the scope of the instant invention may be madewithout departing from the spirit thereof, and the invention includesall such modifications. Corresponding structures, materials, acts, andequivalents of all elements are intended to include any structure,material, or acts for performing the functions in combination with otherelements. Reference to an element in the singular is not intended tomean “one and only one” unless explicitly so stated, but rather “one ormore.” Moreover, when a phrase similar to “at least one of A, B, or C”or “at least one of A, B, and C” is used in the claims or thespecification, the phrase is intended to mean any of the following: (1)at least one of A; (2) at least one of B; (3) at least one of C; (4) atleast one of A and at least one of B; (5) at least one of B and at leastone of C; (6) at least one of A and at least one of C; or (7) at leastone of A, at least one of B, and at least one of C.

1. A system comprising: a network interface in communication with amemory; the memory in communication with a processor; the processor,when executing a computer program, executes operations comprising:determining, by an optimizer module in communication with the processor,a capacity (CAP) from an airline central data repository; forecasting,by the processor and in real-time iteratively throughout a period oftime, a no-show forecast (NSF) based on passenger name recordcharacteristics from a passenger system; determining, by the optimizermodule in communication with the processor and using a flight costprediction model in a forecaster module and in real-time iterativelythroughout the period of time, an optimal booking authorization level(AU) that minimizes an overbooking cost, determining, by a cost enginein communication with the processor and in real-time iterativelythroughout the period of time, a spoiled seat (SS) cost; determining, bythe cost engine in communication with the processor and in real-timeiteratively throughout the period of time, a denied boarding (DB) costbased on a probability of a volunteer not taking the flight; wherein theoverbooking cost is based upon the CAP, the NSF, the SScost and the DBcost, wherein the DB cost is based on actual passengers booked, marketload factors, accommodations cost and a probability a denied boardingwill result in a voucher, and wherein the DB cost is dynamicallycalculated based upon a plurality of forecasts for a re-accommodationcost for each of a plurality of denied passengers for the flight;wherein the DB cost is determined by:DBcost_(i)=DDB_(i)*[(1−ncf)*(voucher_amt*b*pv_(i)+(ill_will+exp_invol_cost_(i))*(1−pv_(i))+HMT_(i))];where, DB cost_(i) is DB cost of the i^(th) passenger who is deniedboarding; ncf is no Compensation Factor, the percentage of DBs that donot qualify to be compensated due to non-compliance, 0≦ncf≦1;voucher_amt is the actual amount of the voucher offered to passengerswho volunteer to DB; b is a breakage factor, the expected percentage ofvoucher dollars that will be used, 0≦b≦1; given i DBs, pv_(i) is theexpected percentage of volunteers, calculated from a linear regressionmodel using historical data, 0≦pv≦1; ill_will is the extra cost addeddue to bad customer image and possible loss of customers due toinvoluntarily denying boarding to passengers; exp_invol_cost_(i) is theexpected payout to an involuntary DB passenger; HMT_(i) is the expectedhotel, meal and transportations costs of the i^(th) DB passenger, basedon the time to accommodate the passenger; and, DDB_(i) is a double DBfactor, increases the DB cost based on the probability that this DBcauses another DB, wherein DDB_(i) increases depending on the loadfactor of an entire directional market and the station load factor forthat day, and wherein DDB_(i)≧1. modeling, by the cost engine incommunication with the processor and in real-time iteratively throughoutthe period of time, DB cost as an aggregate, for each passenger deniedboarding, of a breakage adjusted voucher cost, an involuntary rate draftcost, a rolling denied boarding marginal cost and a secondaryaccommodations cost; updating, by the processor and on a database and inreal-time iteratively throughout the period of time, an authorizationparameter to create an updated authorization parameter for the flightbased upon the AU to maximize revenue for the flight and minimize thecosts of overbooking; providing, by the processor and to a revenuemanagement system and in real-time iteratively throughout the period oftime, the updated authorization parameter, wherein the updatedauthorization parameter impacts the revenue management system and areservation system, wherein the revenue management system determines,based on the updated authorization parameter, a number of additionalseats to be sold for the flight and a respective price for eachadditional seat, wherein the revenue management system transmits to thereservation system the number of additional seats to be sold for theflight and the respective price for each additional seat; creating, bythe processor and in real-time, a voucher for the number of additionalseats for the flight, wherein the voucher changes throughout the daybased on the updating the updated authorization parameter and mostcurrent conditions to minimize costs; and providing, by the processorand in real-time and to a customer mobile device, the voucher for thenumber of additional seats for the flight.
 2. The system of claim 1,further comprising: providing, by the processor, a certain number ofupdated tickets to access the flight; providing access information, bythe processor and to an airline kiosk, that allows access to the flightto certain passengers with the updated tickets, wherein the airlinekiosk provides an updated boarding passes with machine readable data tothe passengers; receiving, by the processor and from an airport scanner,scanned data from the updated tickets, wherein access to the airplane isprovided in response to the airport scanner scanning the machinereadable data on the updated tickets and verifying the machine readabledata on the updated tickets; providing denial information, by theprocessor, that denies access to the flight to denied passengers withthe updated tickets; and compensating, by the processor, the deniedpassengers.
 3. The system of claim 1, the operations further comprisingdetermining the DB cost for a plurality of booking authorization levels(AUs).
 4. The system of claim 3, wherein the determining the DB cost forthe plurality of AUs comprises determining for each of the plurality ofAUs a forecasted number of denied passengers for the flight.
 5. Thesystem of claim 4, the operations further comprising analyzing aplurality of flights in an airline network to identify a plurality ofalternate accommodation (AA) flights, wherein each AA flight in theplurality of AA flights covers at least a same directional market as theflight.
 6. The system of claim 5, wherein the determining there-accommodation cost comprises analyzing booking information for theplurality of AA flights.
 7. The system of claim 6, the operationsfurther comprising selecting for a first denied passenger a first AAflight from the plurality of AA flights, wherein the first deniedpassenger is one of the plurality of denied passengers.
 8. The system ofclaim 7, the operations further comprising, selecting for a seconddenied passenger and based upon the selecting the first AA flight forthe first denied passenger, a second AA flight from the plurality of AAflights, wherein the second denied passenger is one of the plurality ofdenied passengers and the second AA flight is one of the plurality of AAflights.
 9. The system of claim 8, the operations further comprising, inresponse to the second AA flight being scheduled to depart on adifferent day than the flight, adding an accommodations cost to the DBcost associated with the second denied passenger.
 10. The system ofclaim 9, further comprising: storing, by the processor, the updatedauthorization parameter in the database; tuning, by the processor, thedatabase to optimize database performance, wherein the tuning includesplacing frequently used files as indexes on separate file systems toreduce in and out bottlenecks; designating, by the processor, a keyfield in data tables to speed searching for the updated authorizationparameter; sorting, by the processor, the updated authorizationparameter according to a known order to simplify the lookup process;obtaining, by the processor, the updated authorization parameter fromthe database.
 11. The system of claim 4, wherein the determining theforecasted number of denied passengers for the flight comprisesdetermining based upon at least two of the CAP, the AU and the NSF. 12.The system of claim 11, wherein the determining the forecasted number ofdenied passengers for the flight determining based upon at least one ofa binomial distribution, a poisson distribution and a normalapproximation of a binomial distribution.
 13. A system, comprising: anetwork interface communicating with a memory; the memory communicatingwith a processor; the processor, when executing a computer program,executes operations comprising: determining, by an optimizer module incommunication with the processor, a capacity (CAP) from an airlinecentral data repository; forecasting, by the processor and in real-timeiteratively throughout a period of time, a no-show forecast (NSF) basedon passenger name record characteristics from a passenger system;determining, by the optimizer module in communication with the processorand using a flight cost prediction model in a forecaster module and inreal-time iteratively throughout the period of time, an optimal bookingauthorization level (AU) that minimizes an overbooking cost,determining, by a cost engine in communication with the processor and inreal-time iteratively throughout the period of time, a spoiled seat (SS)cost; determining, by the cost engine in communication with theprocessor and in real-time iteratively throughout the period of time, adenied boarding (DB) cost based on a probability of a volunteer nottaking the flight; wherein the overbooking cost is based upon the CAP,the NSF, the SScost and the DB cost, wherein the DB cost is based onactual passengers booked, market load factors, accommodations cost and aprobability a denied boarding will result in a voucher, and wherein theDB cost is dynamically calculated based upon a plurality of forecastsfor a re-accommodation cost for each of a plurality of denied passengersfor the flight; wherein the DB cost is determined by:DBcost_(i)=DDB_(i)*[(1−ncf)*(voucher_amt*b*pv_(i)+(ill_will+exp_invol_cost_(i))*(1−pv_(i))+HMT_(i))];where, DB cost_(i) is DB cost of the i^(th) passenger who is deniedboarding; ncf is no Compensation Factor, the percentage of DBs that donot qualify to be compensated due to non-compliance, 0≦ncf≦1;voucher_amt is the actual amount of the voucher offered to passengerswho volunteer to DB; b is a breakage factor, the expected percentage ofvoucher dollars that will be used, 0≦b≦1; given i DBs, pv_(i) is theexpected percentage of volunteers, calculated from a linear regressionmodel using historical data, 0≦pv≦1; ill_will is the extra cost addeddue to bad customer image and possible loss of customers due toinvoluntarily denying boarding to passengers; exp_invol_cost_(i) is theexpected payout to an involuntary DB passenger; HMT_(i) is the expectedhotel, meal and transportations costs of the i^(th) DB passenger, basedon the time to accommodate the passenger; and, DDB_(i) is a double DBfactor, increases the DB cost based on the probability that this DBcauses another DB, wherein DDB_(i) increases depending on the loadfactor of an entire directional market and the station load factor forthat day, and wherein DDB_(i)>1. modeling, by the cost engine incommunication with the processor and in real-time iteratively throughoutthe period of time, DB cost as an aggregate, for each passenger deniedboarding, of a breakage adjusted voucher cost, an involuntary rate draftcost, a rolling denied boarding marginal cost and a secondaryaccommodations cost; updating, by the processor and on a database and inreal-time iteratively throughout the period of time, an authorizationparameter to create an updated authorization parameter for the flightbased upon the AU to maximize revenue for the flight and minimize thecosts of overbooking; providing, by the processor and to a revenuemanagement system and in real-time iteratively throughout the period oftime, the updated authorization parameter, wherein the updatedauthorization parameter impacts the revenue management system and areservation system, wherein the revenue management system determines,based on the updated authorization parameter, a number of additionalseats to be sold for the flight and a respective price for eachadditional seat, wherein the revenue management system transmits to thereservation system the number of additional seats to be sold for theflight and the respective price for each additional seat. creating, bythe processor and in real-time, a voucher for the number of additionalseats for the flight, wherein the voucher changes throughout the daybased on the updating the updated authorization parameter and mostcurrent conditions to minimize costs; and providing, by the processorand in real-time and to a customer mobile device, the voucher for thenumber of additional seats for the flight.
 14. The system of claim 13,the operations further comprising: analyzing a plurality of flights inan airline network to identify a plurality of alternate accommodation(AA) flights, wherein each AA flight the plurality of AA flights coversat least a same directional market as the flight; and determining there-accommodation cost by analyzing booking information for the pluralityof AA flights.
 15. The system of claim 14, the operations furthercomprising: selecting for a passenger_(i) an AA flight_(j) from theplurality of AA flights; and assigning passenger_(i) to AA flight_(j),wherein j is a member of (1 . . . J) flights, wherein J=the total numberof the plurality of AA flights, wherein i is a member of (1 . . . I)passengers, and wherein I=the total number of the plurality of deniedpassengers for the flight.
 16. The system of claim 15, the operationsfurther comprising: selecting, for a passenger_(i+1) and based upon theassigning passenger_(i) to AA flight_(j), an AA flight_(j+1) from theplurality of AA flights; and assigning passenger_(i+1) to AAflight_(j+1).
 17. The system of claim 16, wherein AA flight_(j) and AAflight_(j+1) are the same flight.
 18. The system of claim 13, theoperations further comprising determining the No-Show-Rate by:determining a booked passenger no-show forecast (NSF) for each bookedpassenger on the flight, wherein the booked passenger NSF is a basedupon whether the respective booked passenger flew on a previous leg of apassenger itinerary; accumulating each respective booked passenger NSFto determine a booked passenger NSF for the flight; aggregating, by theprocessor, the booked passenger NSF for the flight and an unbookedpassenger NSF to create a flight NSF; and calculatingNo-Show-Rate=(1−flight NSF).
 19. A computer-based method for determiningan authorization level (AU) for a flight, the method comprising:obtaining, by the processor, a capacity (CAP) and a no-show forecast(NSF) for a flight; determining, by the processor, an optimal bookingauthorization level (AU) that minimizes an overbooking cost, wherein theoverbooking cost is based upon the CAP, the NSF, a spoiled seat (SS)cost and a denied boarding (DB) cost, wherein the DB cost is dynamicallycalculated based upon a plurality of forecasts for a re-accommodationcost for each of a plurality of denied passengers for the flight; andupdating, by the processor and on a database, an authorization parameterfor the flight based upon the AU.